-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(visual-editing): add svelte optimistic state support #2307
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
1 Skipped Deployment
|
2bf847a
to
633bf18
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've refactored the deprecation markings to follow the same approach we use for marking:
import createClient from '@sanity/client' // tsdoc says you should migrate to `import {createClient} from '@sanity/client'`
in @sanity/client
.
Do the changes to exports make sense?
Yep!
Does the Svelte useOptimistic implementation follow the existing React logic OK?
And yep! Let's go!
This PR adds optimistic state support for Svelte via the
useOptimistic
export in@sanity/visual-editing/svelte
.I've also re-worked a lot of the existing optimistic related exports, and added a new
@sanity/visual-editing/optimistic
export path which exposes the non-framework specific parts needed for e.g. Nuxt to implement this functionality.Going forward we should recommend that the React version of
useOptimistic
be imported from@sanity/visual-editing/react
rather than the root@sanity/visual-editing
export path. I've added that export to the React specific path but haven't removed anything from that root path for now, so no breaking changes. I'm not sure how we can mark the root exports specifically as deprecated with TSDoc, open to ideas there!So the two big things to review are:
useOptimistic
implementation follow the existing React logic OK?